In some online scenarios, a user may establish a user account to be used to access one or more network services or resources (collectively, “account network resources”) within an account network. In support of this scenario, an account authority service (e.g., an “identity provider” or “security authority”) provides a shared identity function that authenticates a single set of credentials to allow the user to access these account network resources. For example, by setting up an account with an account authority service, a user can configure a single set of credentials that can be used to access an email service, a calendaring service, an instant messaging service, a text messaging service, a blogging service, an online music service, a photosharing service, various e-commerce site, various remote devices, etc. within the account network. The term “account network” generally refers to the network of account network resources that have trust relationships with an account authority service.
In this context, a federated security architecture facilitates the use of a single set of credentials by providing mechanisms that enable authentication and authorization across different account networks. A federation is a collection of account authorities that have established trust among them. A realm corresponds to the smallest unit in a federation and represents a single unit of security administration or trust, such as a single organization. An account authority may support multiple realms. One of the simpler forms of a realm is a domain that represents an organization (e.g., CompanyXYZ.com). The levels of trust may vary but actions of a realm typically include authentication and almost always include authorization. A typical federation, for example, might include a number of organizations that have established trust for shared access to a set of resources. Federated security enables collaboration across multiple systems, networks, and organizations in different trust realms.
Typically, a user can sign into their appropriate account authority service (e.g., in their “home” realm) and receive a security token that can be used to access a desired network service. Furthermore, if the desired network service is in a different realm in the federation than the account authority service, the account authority service in one realm can send the appropriate security token for use in accessing the desired network service in the other realm, if the two realms have established a trust relationship. However, if a user attempts to access the network service before authenticating with an appropriate account authority service and/or before acquiring the security token, a challenge left to the network service is what to do to obtain the correct security token to allow access to the user (e.g., where to send the user to get the user's credentials validated). In addition, exposure of the user's credentials from one realm to entities in another realm presents security concerns, so it is undesirable to leave the authentication up to the network service or account authority service of the other realm. It remains a challenge to address these concerns, particularly without dramatically complicating or modifying the federated authentication user experience.